What is a fault tree?
The fault tree analysis (FTA) is a deductive representation. It begins with an event that one wishes to avoid and examines what situations can produce it. Each branch is developed through logical relationships until it reaches basic events or elements that are not developed further due to the limitations of the study.
It can be used qualitatively to understand vulnerabilities or complemented with a quantitative estimate. Its usefulness depends on the model accurately representing the real system. A large diagram is not necessarily better if it contains imprecise relationships, obscures assumptions, or conflates different consequences under a single description.
Define the top event and scope
The overarching event description must clearly indicate what occurs and under what conditions. Expressions like “general failure” are too ambiguous to construct a verifiable logic. It is advisable to define the lost function or the dangerous situation, along with the operating mode and the period or demand to be analyzed.
The scope includes relevant equipment, supplies, interfaces, and human actions. It also specifies what is excluded and why. Design, operation, and maintenance information should allow for verification of the proposed relationships. When information is missing, the tree can highlight a branch pending development, making that limitation visible.
Logic gates and model construction
An OR gate represents situations where any one of the connected events is sufficient to produce the next. An AND gate represents a combination where all defined events must occur. The time condition and the meaning of concurrency need to be consistent with the scenario being studied.
The tree is built in levels, checking each relationship before proceeding. Causes must be at the same level of description when compared. If one branch uses physical failures and another uses general expressions like mismanagement, it will be necessary to specify the mechanisms that connect those factors to the higher-level event.
Dependencies and common causes
Two physically separate devices can share power, environment, maintenance, or information. Therefore, independence should not be assumed simply because two devices exist. A single event can disable several functions and must be represented in a way that prevents the analysis from attributing nonexistent redundancy.
Repeated events require consistent identification. If they appear as distinct events in separate branches, the estimate can be misleading. Qualitative analysis helps locate minimal combinations capable of producing the higher-level event and recognize individual failures that compromise multiple protections simultaneously. A minimum failure set describes a combination sufficient to produce the higher-level event, which ceases to be sufficient if any of its elements are removed. Its interpretation helps prioritize vulnerability studies. It should not be confused with a list of components to replace: preventive decision-making requires reviewing mechanisms, consequences, and design options.
When and how to quantify
Quantification requires adequate data on failures, demand, times, and availability, with an interpretation compatible with the model. A failure rate, a probability of failure on demand, and a probability over a period are not interchangeable. Assumptions must be documented so that another person can review the calculation.
Under appropriate conditions of independence, probabilistic relationships can be applied, but they should not be used mechanically for every logic gate. Dependencies, repairs, and sequences may require more elaborate models. Presenting many decimal places does not compensate for a lack of data. It is preferable to express uncertainty and analyze sensitivity than to offer a seemingly exact figure.
Differences with other analyses
A cause tree is typically used to reconstruct the events of an accident. A fault tree models possible combinations that lead to a specific event. Both use relationships between events, but their purpose and methods for justifying the branches differ.
FMEA starts with functions or components and examines their potential failures. Bow-tie analysis connects threats, the top event, consequences and barriers. These methods can inform the fault tree, provided that the relationships are checked and conclusions are not automatically transferred from one format to another.
Practical example
The loss of a protective function during operation is being investigated. The team identifies two channels that, on the surface, appear to provide redundancy. Upon reviewing documentation and maintenance records, they discover that both depend on the same auxiliary power supply, the loss of which could affect both simultaneously.
The tree diagram incorporates this common cause and shows that it is not enough to simply multiply individual failure probabilities as if the channels were independent. The team reviews the design and the necessary checks. The example illustrates the usefulness of logical reasoning; the technical solution requires installation-specific data and validation.
Preventive use and review
The results should be translated into decisions regarding design, maintenance, testing, procedures, or further analysis. Each recommendation requires a responsible person and evidence of its completion. When a system condition changes, change management should review whether the tree remains representative.
Among the most frequent errors are misdefining the overarching event, omitting shared resources, duplicating events, and confusing probabilities with frequencies. The tree should help understand and improve safety, not serve as a graphical justification created after deciding that the risk is acceptable.
